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Résumé. Les entrepôts de données XML proposent une base intéressante pour 
les applications décisionnelles qui exploitent des données hétérogènes et prove- 
nant de sources multiples. Cependant, les performances des SGBD natifs XML 
étant actuellement limitées, il est nécessaire de trouver des moyens de les opti- 
miser. Dans cet article, nous proposons un nouvel index spécifiquement adapté à 
l'architecture multidimensionnelle des entrepôts de données XML, qui élimine 
le coût des jointures tout en préservant l'information contenue dans l'entrepôt 
initial. Une étude théorique et des résultats expérimentaux démontrent l'effica- 
cité de notre index, même lorsque les requêtes sont complexes. 



1 Introduction 



Les technologies entrant en compte dans les processus décisionnels, comme les entrepôts 
de données (data warehouses), l'analyse multidimensionnelle en ligne (On-Line Analysis Pro- 
cès s ou OLAP) et la fouille de données (data mining), sont désormais très efficaces pour traiter 
des données simples, numériques ou symboliques. Cependant, les données exploitées dans le 
cadre des processus décisionnels sont de plus en plus complexes. L'avènement du Web et la 
profusion de données multimédia ont en grande partie contribué à l'émergence de cette nou- 
velle sorte de données. Dans ce contexte, le langage XML peut grandement aider à l'intégration 
et à l'entreposage de ces données. C'est pourquoi nous nous intéressons aux travaux émergents 
sur les entrepôts de données XML ( Wolfgang et al. , 2003 ; Baril et Bellahsène, 2003 ; Pokorny 



200 1 1 [Golf arelli et âT| [200 1 ) . Cependant, les requêtes décisionnelles exprimées en XML sont 
généralement complexes du fait qu'elles impliquent de nombreuses jointures et agrégations. 
Par ailleurs, les systèmes de gestion de bases de données (SGBD) natifs XML présentent ac- 
tuellement des performances médiocres quand les volumes de données sont importants ou que 
les requêtes sont complexes. Il est donc crucial lors de la construction d'un entrepôt de données 
XML de garantir la performance des requêtes XQuery qui l'exploiteront. 

Plusieurs études traitent de l'indexation des données XML ( K.Gu ptâet al.[ Yeh et Ga rdarin 



200 1[ |Chung et al.[ |2002| ). Ces index optimisent principalement des requêtes exprimées en 
expressions de chemin. Or, dans le contexte des entrepôts de données XML, les requêtes sont 
complexes et comportent plusieurs expressions de chemin. De plus, ces index opèrent sur un 
seul document et ne prennent pas en compte d'éventuelles jointure s, qui sont courantes dans les 
requêtes décisionnelles. A notre connaissance, seul l'index Fabric (Cooper et al. 2001 ) permet 



actuellement gérer plusieurs documents XML. Cependant, cet index ne prend pas en compte 
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les relations qui peuvent exister entre ces documents (les prédicats de jointure, notamment) et 
n'est donc pas non plus adapté à nos besoins. 

C'est pourquoi nous proposons une structure d'index spécifiquement adaptée aux données 
multidimensionnelles d'un entrepôt XML, c'est-à-dire une structure capable de maintenir des 
données de plusieurs documents XML à la fois tout en préservant l'information contenue dans 
ces données et leur modélisation en étoile. Notre structure d'index, que nous qualifions d'index 
de jointure, permet également d'assurer un meilleur traitement des requêtes décisionnelles 
exprimées en XQuery en éliminant les coûts de jointure. Afin de valider cette proposition, nous 
avons mené une étude théorique ainsi que des expérimentations sur un entrepôt de données 
XML réel. 

Le reste de cet article est organisé comme suit. Nous présentons dans la section [2] le 
contexte de notre étude ainsi que notre structure d'index. Les études théorique et expérimen- 
tale que avons menées pour tester la validité de notre index sont présentés dans la section [3] 
Finalement, nous concluons et discutons nos perspectives de recherche dans la section [4] 

2 Indexation des entrepôts de données XML 

2.1 Contexte 

Afin d'appliquer notre démarche d'optimisation des performances, nous avons sélectionné 
l'architecture d'entrepôt de données XCube (Wolf gâng et al.||2ÔÔ3] ), qui propose une modéli- 
sation en étoile de données stockées dans des documents XML. Ces documents permettent de 
représenter respectivement le schéma et les métadonnées (Schema.xml), les dimensions (Di- 
mensions. xmï) et la table de faits (Table Facts.xml) de l'entrepôt XML. La figure [T] (a) et[T](b) 
représentent les deux derniers documents sous forme de graphes XML. 

Pour l'interrogation de l'entrepôt, nous avons adopté le langage XQuery car il permet de 
formuler des requêtes complexes. La requête Q donne un exemple d'une requête décision- 
nelle exprimée dans ce langage. Cette requête retourne la moyenne des quantités vendues aux 
clients de Lyon, avec regroupement par nom et codes postal. Elle réalise une jointure entre 
le document Dimensions, xml et Table Facts.xml. Notons que XQuery ne permet pas normale- 
ment de faire des opérations de groupement Group by multiples. Dans notre implémentation, 
nous avons donc étendu l'interface d'interrogation du SGBD natif XML eXist ( |Meier| [2002) 
de manière à ce qu'il puisse traiter ce type de requêtes. 

Q : for $a in //dimensionData/classification/Level[@node= 'customers ']/node, $x in//CubeFacts/cube/Cell 
where $b/attribute[@name='cust_city',@value='Lyon'] and $x/dimension /@node=$a/@id and $x/dimension 
/@id= 'customers' 

group by(@cust_first_name,@cust_postal_code) return sum(quantity) 

2.2 Structure de notre index de jointure 

Notre index doit permettre de conserver les relations entre les dimensions et les mesures 
dans un fait. Il présente donc une structure similaire à celle du document TableFacts.xml, à 
l'exception de l'élément attribute. 

Sa structure est présentée dans la figure [T](c). Les étiquettes qui commencent par le ca- 
ractère @ représentent les attributs et les autres représentent les éléments. Chaque cellule est 
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identifiée par des dimensions et un ou plusieurs faits. Un fait (élément Fact) possède deux at- 
tributs, ©id et ©value, qui indiquent respectivement son nom et sa valeur. Chaque dimension 
(élément dimension) est identifiée par deux attributs : ©id qui donne le nom de la dimension 
et ©node qui donne la valeur de l'identifiant de la dimension. De plus, l'élément dimension 
possède un certain nombre d'éléments fils (éléments attribute). Ces éléments sont insérés pour 
stocker les noms et les valeurs des attributs de chaque dimension. Ils sont obtenus depuis le 
document Dimensions. xml. Un élément attribute est caractérisé par deux attributs, ©nom et 
©value, qui indiquent respectivement le nom et la valeur de chaque attribut. 




(a) TableFacts . xml (b) Dimensions . xml (c) Index . xml 



FlG. 1 - Structure en arbre des documents (a) Dimensions. xml, (b) TableFacts. xml et (c) In- 
dex, xml 

La migration des données des documents Dimensions. xml et TableFacts. xml vers la struc- 
ture d'index, et le fait de stocker dans une même cellule les faits, les dimensions et leurs at- 
tributs, nous permet d'éliminer les opérations de jointure. Toutes les informations nécessaires 
pour la jointure sont en effet stockées dans la même cellule. 

3 Validation 

3.1 Etude théorique 

Une requête type définie sur un entrepôt de données XML modélisé selon la spécification 
XCube réalise plusieurs jointures entre les faits stockés dans TableFacts. xml et les dimen- 
sions de Dimensions. xml. Il faut alors vérifier les contraintes suivantes : TableFacts Mid = 
Dimensions. ©node et Table Fact s. ©node = Dimensions. ©id. La première égalité vérifie 
que la dimension composant une cellule est bel et bien la dimension exprimée dans la requête. 
La seconde vérifie que le nœud d'une dimension (équivalent d'une clé primaire) correspond 
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(peut être joint) au nœud, de la même dimension, défini dans une cellule (équivalent d'une clé 
étrangère de la table de faits). 

L'exécution d'une requête sans utilisation de notre index peut se dérouler comme suit. Pour 
chaque dimension définie par @node= 'nom de la dimension', les identifiants @id vérifiant la 
clause Where sont recherchés. Le document Dimensions. xml est parcouru en profondeur, jus- 
qu'au nœud Level. Les fils node du nœud Level sont ensuite parcourus en largeur jusqu'à trou- 
ver le nœud dont la valeur de @node est égale au nom de la dimension spécifié dans la requête. 
Le coût de ce parcours est égal au nombre de nœuds Level du document Dimensions. xml, 
c'est-à-dire le nombre de dimensions dans le schéma, dénoté \dimension\. Si plusieurs di- 
mensions sont définies, le parcours donne alors lieu à autant de nœuds que de dimensions. En 
revanche, le coût de ce parcours reste invariant car tous les nœuds Level sont parcourus. Pour 
chaque nœud trouvé, ses fils sont parcourus en profondeur jusqu'à trouver la liste des @id véri- 
fiant les conditions @name= 'nom de l'attribut' et @ value- 'valeur de l'attribut' . Le coût de ce 
parcours est égal au nombre de fils attribute. En résumé, le coût de traitement des dimensions 
est égal à \ai | * \di |, où \ai | désigne le nombre d'attributs de chaque dimension et \di | le nombre 
d'éléments node, c'est-à-dire le nombre de fils de chaque dimension. Pour réaliser une jointure 
entre les dimensions du document Dimensions. xml et les faits du document Table Facts. xml, les 
@id retrouvés dans le traitement des dimensions sont recherchés dans les faits. Le document 
Table Facts. xml est alors parcouru en profondeur jusqu'au niveau Cell. Le coût de ce parcours 
est égal à 2. Les cellules sont ensuite parcourues en largeur afin de trouver les dimensions dont 
le fils @id est égal à @node de Dimensions. xml et ©node est égal à @id de Dimensions. xml. En 
résumé, le coût de traitement du document Table Facts. xml est \Cell\, où \Cell\ est le nombre 
de cellules du document Table Facts. xml. Le coût de traitement d'une requête est donnée par la 
formule E 'sans-index = ((\Cell\) * | Dimension]) * (\Dimension\ + * |^|)). 

L'exécution d'une requête, avec utilisation de notre index (stocké dans le document In- 
dex.xmï), peut se dérouler comme suit. Pour chaque dimension définie par @node= 'nom de 
la dimension', les identifiants @id vérifiant la clause Where sont recherchés. Le document In- 
dex.xml est parcouru en profondeur, jusqu'au nœud Cell. Le coût de ce parcours est égal au 
nombre de cellules dans le document Index.xml. Les fils dimension du nœud Cell sont en- 
suite parcourus en largeur jusqu'à trouver le nœud dont la valeur de @id est égale au nom de 
la dimension spécifié dans la requête. Le coût de ce parcours est égal au nombre de nœuds 
dimension du document Index.xml, c'est-à-dire le nombre de dimensions dans le schéma de 
l'entrepôt de données : \dimension\. Pour chaque nœud trouvé, ses fils sont parcourus en pro- 
fondeur jusqu'à trouver le nœud attribute vérifiant les conditions @name= 'nom de l'attribut' 
et @ value = 'valeur de l'attribut'. Le coût de ce parcours est égal au nombre de fils attribute 
\di\. En résumé, le coût de traitement d'une requête qui exploite notre structure d'index est 
donné par la formule E in dex = \Cell\ * (\Dimension\ + |a^|). 

La figure [2] (a) représente la variation des coûts E sans _ in( i ex et E index en fonction du 
nombre de cellules. Nous constatons que l'utilisation de notre index permet un gain de facteur 
14000 en moyenne. 

3.2 Expérimentations 

En complément de notre étude théorique, nous avons effectué des expérimentations afin de 
tester l'efficacité de notre proposition de structure d'index. Nous avons généré un entrepôt de 
données XCube implanté au sein du SGBD XML natif eXist. Construit à partir d'un entrepôt de 
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données relationnel test classique, cet entrepôt est constitué d'une table de faits sales (4,92 Mo) 
et de cinq dimensions channels, promotions, customers, products et times (3,11 Mo). Nous 
avons effectué nos tests sur une machine dotée d'un processeur Intel Pentium 4 GHz avec 1 GB 
de mémoire et un disque dur IDE. Nous avons exécuté la requête décisionnelle XQuery de la 
section |2Jl avec et sans utilisation de notre index et en faisant varier la taille de l'entrepôt. 
La figure [2] (b) présente les résultats obtenus exprimés en temps d'exécution par rapport au 
nombre de cellules (faits) dans le document Table Facts.xml. 




50 100 150 200 250 300 350 400 450 500 50 100 150 200 250 300 350 400 450 50C 



nombre de cellules nombre de cellules 

a - Résultat théorique b - Résultat Expérimental 



FlG. 2 - Résultats 



La figure [2] (b) montre qu'avec l'utilisation de notre index, nous obtenons des temps de 
traitement en moyenne 25669 fois inférieurs à ceux obtenus sans utiliser notre index. De plus, 
cette figure est semblable à celle qui représente nos estimations théoriques (figure [2] (b)). Nous 
avons également utilisé notre structure d'index pour traiter la requête sur la totalité des cellules 
du documents TableFatcs.xml. Nous avons obtenu un temps d'exécution de moins de deux 
secondes, alors que le système s'est avéré incapable de répondre à la requête dans un temps 
raisonnable lorsque nous n'utilisions pas notre index. 



4 Conclusion et perspectives 

Nous avons présenté dans cet article un nouvel index de jointure spécifiquement adapté aux 
entrepôts de données XML. Cette structure de données permet d'optimiser les temps d'accès 
à plusieurs documents XML en éliminant le coût de jointure, tout en préservant l'information 
contenue dans l'entrepôt initial. Une étude de complexité et des expérimentations nous ont 
permis de démontrer l'efficacité de notre index même lorsque les requêtes sont complexes et la 
taille de l'entrepôt volumineuse. Ces expérimentations nous ont par ailleurs amenés à étendre 
la syntaxe des requêtes XQuery afin qu'elles puissent supporter des clauses de regroupement 
(Group by) multiples. 

Les perspectives de ce travail se situent dans le cadre du développement des SGBD natifs 
XML, qui vise à les doter des mêmes fonctionalités et performances que les SGBD relationnels. 
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Premièrement, notre index pourrait être directement intégré au sein d'un SGBD natif XML. Il 
serait également indispensable de mettre au point une stratégie de maintenance incrémentale 
de la structure de données de notre index lorsque les données sources sont mises à jour. Par 
ailleurs, notre mécanisme de réécriture de requêtes pourrait également être directement intégré, 
notamment au niveau de la modélisation des vues. Finalement, les modifications que nous 
avons apportées à la clause de regroupement Group by de XQuery pourraient aussi faire objet 
d'une proposition d'extension de la syntaxe de ce langage. 
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Summary 

XML data warehouses form an interesting basis for décision- support applications that ex- 
ploit heterogeneous data from multiple sources. However, XML-native database Systems cur- 
rently bear limited performances and it is necessary to research ways to optimize them. In 
this paper, we propose a new index that is specifically adapted to the multidimensional archi- 
tecture of XML warehouses and éliminâtes join opérations, while preserving the information 
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contained in the original warehouse. A theoretical study and expérimental results demonstrate 
the efficiency of our index, even when queries are complex. 



